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(57) Abstract: The invention relates to a method and a device for a vehicle-related telematics service, whereby the telematics service 
is divided into partial functionalities which are, in turn, distributed between the server and the terminal. 

(57) Zusammenfassung: Es werden ein Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst vorgeschlagen, 
bei welchem der Telematikdienst in Teilfunktionalitaten untergliedert ist und these Teilfunktionalitaten auf Server und Endgerat 
aufgeteilt sind. 
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Verfahren und Vorrichtung ftir einen fahrzeugbezogenen Telematikdienst 
Stand der Technik 

Die Erfindung betrifft ein Verfahren und Vorrichtung fur einen fahrzeugbezogenen 
Telematikdienst wie das Einwirken auf wenigstens eine Funktionalitat in einem Fahrzeug 
iiber eine Luftschnittstelle, z.B. ein Mobilfunknetz, insbesondere in Verbindung mit der 
Ferndiagnose von Kraftfahrzeugen. 

Die zunehmende Vernetzung von Steuergeraten in heutigen Kraftfahrzeugen bietet immer 
bessere Einwirkungsmoglichkeiten auf Funktionalitaten im Kraftfahrzeug, z.B. bessere 
Diagnosemoglichkeiten im Fehlerfall oder Moglichkeiten zur Fernbedienung von 
Funktionen und/oder Komponenten des Fahrzeugs. In diesem Zusammenhang bestehen 
Konzepte, mit Hilfe eines mobilfunkgestiitzten Einwirkens zuverlassig und sicher auf die 
Funktionalitat im Fahrzeug iiber beliebige Entfernungen hinweg zuzugreifen, 
beispielsweise uber eine Ferndiagnose zuverlassige und qualitativ hochwertige 
Fehleranalysen durch ein Service-Center bzw. einen Ferndiagnose-Server, der eine 
entsprechende Diagnose-Datenbank umfasst, durchzufiihren. GemaB diesen Ansatzen 
werden im Fahrzeug integrierte Kommunikationssysteme wie beispielsweise 
Mobiltelefone und/oder GSM-gesttitzte Telematikendgerate genutzt, um eine 
Dateniibertragung zwischen den an ein Fahrzeugnetzwerk angeschlossenen Steuergeraten 
und/oder Komponenten und dem Server des Service-Centers durchzufiihren. Einen 
Vorschlag fur ein derartiges System beschreibt die DE 100 26 754 Al. Eine konkrete 
Realisierung hinsichtlich der tJbertragungsinhalte zwischen Server und Endgerat sowie 
hinsichtlich der Ausgestaltung von Endgerat bzw. Server werden nicht angegeben. 



Vorteile der Erfindung 
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Durch die Aufteilung der Funktionen, z.B. Diagnosefunktionen, zwischen Endgerat und 
Server (Partitionieren von Teilfunktionen) wird eine erhebliche Ressourcenerspamis im 
Fahrzeugendgerat erreicht. Besonders vorteilhaft ist, dass zeitunkritische, 
fahrzeugspezifische Funktionen, mit denen das Einwirken auf die ausgewahlte 
Funktionalitat gesteuert wird, nicht im Fahrzeugendgerat, sondern im Server vorgehalten 
werden und von diesem uber die Luftschnittstelle ubertragen werden. Dadurch wird 
vermieden, dass ein zusatzliches, speziell auf die Anwendung insbesondere hinsichtlich 
vom Fahrzeugnetzwerk vorgegebenen zeitlichen Randbedingungen zugeschnittenes 
Applikations-Protokoll fur die Luftschnittstelle notwendig ist, so dass auf ubliche 
Standard-Protokolle fur die Luftschnittstelle zuruckgegriffen werden kann. Erganzend 
erlaubt die Ubermittlung von fahrzeugspezifischen Informationen iiber die 
Luftschnittstelle eine einheitliche, parametrisierbare Funktionalitat im Endgerat sowie 
eine fahrzeugunabhangige Implernentierung im Endgerat. Eine besonders hohe 
Flexibility des Systems wird erreicht, die sich auch sich andernde Ausstattungen der 
Fahrzeuge anpassen kann. 

Bei der Ferndiagnose sind Anderungen oder Verbesserungen im Bezug auf die Diagnose 
selbst, sofern diese nicht Onboard in den Steuereinheiten des Fahrzeugs ablaufen, im 
Server moglich. Dies betrifft vor alien den Ablauf und Umfang (iibertragene Daten) des 
Ferndiagnosevorgangs. 

Besondere Vorteile werden in Verbindung mit der Ferndiagnose erreicht, wenn die 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls uber die Luftschnittstelle 
vom Server zum Endgerat ubertragen werden. 

Durch die Ressourcenerspamis im Fahrzeugendgerat, insbesondere durch die 
Auslagerung zeitunkritischer Vorgange in den Server des Service-Centers wird eine 
einfache und schnelle Umsetzung auf das Fahrzeugnetzwerk im Endgerat moglich. 

Somit ergibt sich insgesamt eine effiziente und vor allem mit geringem Aufwand 
implementierbare Vorgehensweise zum Einwirken auf eine Fahrzeugfunktionalitat, vor 
allem zur Ferndiagnose, Femwartung, Fernsteuerung, Software-Download, etc. bei 
Kraftfahrzeugen. 
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Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von 
Ausfuhrungsbeispielen bzw. aus den abhangigen Patentanspruchen. 

Zeichnung 

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten 
Ausfiihrungsformen anhand der Ferndiagnose eines Kraftfahrzeugs naher erlautert. 
Figur 1 zeigt ein Prinzipbild eines Ferndiagnosesystems. 

In Figur 2 ist als Ubersichtsdarstellung die Aufteilung der Diagnosefunktionalitat 
zwischen fahrzeugseitigem und serverseitigemTeil des Systems dargestellt. Insbesondere 
ergeben sich daraus auch Ausgestaltungen des Fahrzeugendgerats bzw. des Servers des 
Service-Centers. 

Figur 3 zeigt ein Ablaufdiagramm, welches den grundsatzlichen Ablauf der Ferndiagnose 
insbesondere im Hinblick auf die Ubertragung zwischen Server und Endgerat sowie im 
Hinblick auf die Funktionen des Endgerats bzw. des Servers in einem bevorzugten 
Ausfuhrungsbeispiel darstellt. 

Figur 4 zeigt die Kommunikation zwischen Server und Endgerat sowie zwischen 
Endgerat und zu diagnostizierendem Steuergerat sowie die in den jeweiligen Einheiten 
ablaufenden Vorgange im Detail anhand eines bevorzugten Ausfiihrungsbeispiels. 

Beschreibung von Ausfuhrungsbeispielen 

Figur 1 zeigt ein Ubersichtsbild eines Systems fur einen fahrzeugbezogenen 
Telematikdienst, wobei Informationen zwischen einem Fahrzeug (dort Endgerat) und 
einem Server uber ein Mobilfunknetz bzw. uber ein Datennetz, wie beispielsweise das 
Internet, ausgetauscht werden. Eine derartige Konfiguration wird in Verbindung mit 
Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung, Software Download, etc. 
eingesetzt. Unter Fernwirkung bzw. Femabfrage wird dabei im wesentlichen die 
Femsteuerung von Fahrzeugfunktionen, insbesondere Komfortfunktionen wie das 
Einschalten der Standheizung, etc., sowie das Abfragen von Fahrzeugstati und/oder 
Betriebsparametern verstanden. Dabei initiiert der Nutzer eine Kommunikation mit dern 
Fahrzeug uber einen zentralen Server oder er kommuniziert direkt mit dem Fahrzeug. 
Ferndiagnose umfasst das Fernauslesen von Diagnosedaten aus dem Fahrzeug, deren 
Analyse und ggf. das Erzeugen einer Empfehlung fur das weitergehende Handeln. 
Analyse der Daten und Generierung der Empfehlung erfoigt dabei durch einen zentralen 
Server, der mit dem Fahrzeug uber ein Mobilfunknetz, uber ein drahtgebundenes Netz 
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und/oder Liber ein Datennetz wie beispielsweise das Internet mit dem Kraftfahrzeug in- 
Verbindung steht. Ferner ist in diesem Zusammenhang als Funktion der sogenannte 
Software-Download bzw. das Remote-Flashing zu nennen, mit deren Hilfe ein neuer 
Programmcode oder Parameter auf per Software konfigurierbare Systeme im Fahrzeug, 
beispielsweise Steuergerate, aufgebracht werden, urn die Funktionalitaten oder die 
Leistungsfahigkeit zu erhohen. Auch hier erfolgt die Kommunikation iiber ein 
Mobilfunknetz, ein drahtgebundenes Netz und/oder beispielsweise das Internet 
ausgehend von einem zentralen Rechner (Server) bzw. Service-Center. Fernwartung stellt 
im wesentlichen die Uberwachung des Fahrzeugzustandes und den Zugriff auf die 
Wartungsdaten im Fahrzeug von einer zentralen Stelle aus dar, urn zu uberprufen, ob, 
wann und welche MaBnahmen zur Wahrung des Sollzustandes durchgefuhrt werden. Ein 
Beispiel hierfur ist das dynamische Anpassen von Wartungsintervallen. Allgemein 
werden diese Funktionalitaten hier unter demBegriff des fahrzeugbezogenen 
Telematikdienstes subsumiert. 

Figur 1 zeigt einen fahrzeugseitigen Teil 1 sowie einen serverseitigen Teil 2. Beide Teile 
sind iiber eine Kommunikationsschnittstelle 3, insbesondere eine Luftschnittstelle, 
beispielsweise uber ein Mobilfunknetz miteinander verbunden. Der fahrzeugseitige Teil 
besteht aus einem Endgerat 4, beispielsweise einem Telematikendgerat, welches iiber 
eine weitere Schnittstelle 5 mit der Fahrzeugelektronik 6 verbunden ist. Der serverseitige 
Teil 2 besteht aus einem Server 7, welcher beispielsweise von einem Service-Center, dem 
Fahrzeughersteller oder einem Zulieferer betrieben wird, und der uber eine Schnittstelle 8 
mit einem Datenspeicher 9 in Verbindung steht, in dem beispielsweise im Rahmen einer 
Datenbank fahrzeugbezogene Daten und/oder Kommandos und/oder Programme abgelegt 
sind. Wie nachfolgend im Detail beschrieben, werden bei dem dargestellten Client- 
Server-System Teilfunktionen partitioniert, d.h. dem Server und den Client bestimmte 
Funktionalitaten eines Telematikdienstes zugeordnet. Dabei wird von einer vollstandigen 
Vernetzung der zu diagnostizierenden bzw. zu steuernden Steuergerate im Fahrzeug mit 
demEndgerats z.B. durch einen CAN-Bus sowie von der Verfugbarkeit der Schnittstelle 
3, insbesondere einer Mobilfunkschnittstelle im Kraftfahrzeug, ausgegangen. Die 
bekannten, unterschiedlichen Verfahren fur die Erfassung von Diagnosedaten, 
beispielsweise uber eine CAN-Bus-Schnittstelle, lassen sich in nichtzeitkritische und 
zeitkritische Anwendungen aufteilen. Zu den nichtzeitkritischen Anwendungen gehort 
beispielsweise die Ablaufsteuerung des Diagnose-Testers, mit Zugriff auf eine 
Datenbank, sowie das Diagnose-Protokoll selbst, beispielsweise das Protokoll KWP2000 
bzw. Varianten davon. Zeitkritische Anwendungen sind das Transport-Protokoll des 
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Fahrzeugnetzes (z.B. CAN-Transport-Protokoll) oder Varianten davon, dessen 
Kommunikationsschicht (z.B. CAN-Kommunikationsschicht) sowie der Bus (z.B. CAN- 
Bus) selbst. Wesentlich ist, dass bei der ImpJementierung der Telematikfunktion im 
Kraftfahrzeug die zeitkritischen Vorgange gegenuber dem unsichereren Mobilfunkkanal 
entkoppelt werden. Daher werden alle oder ein Teil der relevanten Funktionen aus dem 
Fahrzeug ausgelagert, bei denen keine engen zeitlichen Anforderungen bestehen, 
insbesondere Anforderungen bezugliche einer minimalen oder rnaximalen Zeitdauer 
zwischen Kommando und Antwort bei einer Datenubertragung. Im Extremfall bleibt 
daher lediglich der zeitkritische Datentransport auf dem Fahrzeug-Bus (z.B, CAN-Bus 
oder Ahnliches), welcher durch Funktionen des Transport-Protokolls wie beispielsweise 
die Fragmentierung und Defragmentierung komplexer Nachrichten, realisiert ist, auf der 
Client- bzw. Fahrzeugseite zuruck. Der Funktionsumfang des in der Regel komplexeren 
und fahrzeugspezifischen Dienste-Protokolls (z.B. Diagnoseprotokoll) wird dabei auf 
einen entsprechenden Server (z.B. Diagnoseserver) ausgelagert. Im Anwendungsfall der 
Ferndiagnose werden neben der Ubertragung fahrzeugspezifischer Diagnose-Kommandos 
auf der Basis des jeweils verwendeten Diagnose-Protokolls femer zusatzliche 
Informationen zwischen der Server- Applikation (Ablaufsteuerung fur den 
Gesamtvorgang) und der Client-Applikation (Ablaufsteuerung zur Datenerfassung) 
ubertragen. Diese Ablaufsteuerungen dienen der Aktivierung des Diagnosevorgangs, der 
Konfiguration der Client-Applikation und der spateren Ubermittlung von Ergebnissen der 
serverseitigen Datenanalyse. In dem skizzierten Beispiel, bei dem alle zeitunkritischen 
Vorgange aus dem fahrzeugseitigen Teil in den serverseitigen Teil des Systems 
ausgelagert wurden, ergibt sich die in Figur 2 dargestellte Systemarchitektur. In anderen 
Ausfuhrungen wird nur ein Teil der nichtzeitkritischen Vorgange ausgelagert, wahrend 
ein Teil im fahrzeugseitigen Endgerat verbleibt. So ist beispielsweise vorstellbar, dass 
fahrzeugspezifische Daten und/oder spezielle fahrzeugspezifische Diagnose-Kommandos, 
die aus Sicherheitsgrunden nicht ausgelagert werden, im fahrzeugseitigen Teil des 
Systems verbleiben. 

In Verbindung mit anderen Telematikdiensten wie der Fernsteuerung von Komponenten, 
den Softwaredownload, etc. wird auf die geschilderte Art und Weise zeitunkritische 
Anwendungen ausgelagert, wahrend zeitkritische Anwendungen im Fahrzeugendgerat 
verbleiben. 

In Figur 2 ist das Fahrzeugendgerat (Client) 4 sowie der Server 7 dargestellt, welche uber 
eine Luftschnittstelle 3 miteinander verbunden sind. Im bevorzugten Ausfuhrungsbeispiel 
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handeltes sich bei der Luftschnittstelle 3 urn ein herkommJiches, beispielsweise auf dem 
GSM-Standard basierendes Mobilfunknetz. In anderen Anwendungen handelt es sich um 
Mobilfunknetze, die mit anderen Standards arbeiten. Der Server umfasst die folgenden 
Module: einMobilfunk-Kommunikations-Protokoll-Modul 7a, ein 
Mobilfunkkommunikation-Modul 7b, ein Ablaufsteuerungs-Modul 7c sowie ein 
fahrzeugspezifisches Diagnose-Protokoll-Modul 7d. Das Fahrzeugendgerat umfasst 
ebenfalls ein Kommunikations-Protokoll-Modul 4a, ein Modul 4b zur Kommunikation 
uber die Mobilfunkschnittstelle, ein Modul 4c zur CAN-Kommunikation sowie ein 
Transport-Protokoll-Modul 4d. Ferner ist eine Ablaufsteuerung 4e im Fahrzeugendgerat 
vorgesehen. Die Module stellen dabei vorzugsweise Softwareprogramme dar. 

Diese Funktionseinheiten haben die folgenden Aufgaben: 

Die Mobilfunkkommunikations-Module 4b, 7b, die sowohl im Endgerat als auch im 
Server vorgesehenen sind, diesen zur stabilen Datenubertragung, zum Verbindungsaufbau 
bzw. -abbau, der Datensicherheit, gegebenenfalls der Verschlusselung, Packetierung, 
etc. Diese Aufgaben werden von ublichen Kommunikationsfunktionseinheiten realisiert 
und sind z.B. im Rahmen der GSM-Standards verfugbar. 

Das im Fahrzeugendgerat vorgesehene CAN-Kommunikation-Modul 4c stellt eine 
hardwareunabhangige Softwareschnittstelle zur Ubertragung von Daten uber einen CAN- 
Bus zu angeschlossenen Steuergeraten dar. Dazu gehoren die Initialisierung und 
Steuerung des CAN-Controllers, die Ubertragung und den Empfang von CAN- 
Bausteinen sowie Uberlauf-Fehlerbehandlungen und Weckfunktionen. Femer umfasst das 
Modul die Funktionen der OSI-Layer 1 und 2 (Physical Layer, Data Link Layer). Das 
Softwaremodule arbeitet dabei im Rahmen der gultigen CAN-Spezifikation. In anderen 
Ausfuhrungen wird anstelle des CAN-Bus ein anderes Bussysteme eingesetzt 
(standardisiert oder kundenspezifisch), wobei das Softwaremodul dann auf der Basis 
einer entsprechenden Spezifikation realisiert ist. 

Die Ablaufsteuerung 7c im Server zerlegt die Diagnose-Grundfunktionen in einzelne 
Teilprozesse bzw. Diagnose-Services, ubernimmt die Initialisierung des Prozesses, 
steuert und beendet den Diagnosevorgang, verarbeitet die erforderlichen Parameter- und 
gegebenenfalls Protokoll-Mechanismen fur den Diagnosevorgang und steuert den 
Gesamtvorgang zeitlich. Ferner werden hier die ermittelten Diagnosedaten ausgewertet, 
■ gegebenenfalls eine Generierung einer Empfehlung durchgefuhrt. Ferner ubernimmt die 
Ablaufsteuerung den Zugriff auf die Diagnose-Datenbank des Servers. Die 
Ablaufsteuerung stellt ein Software-Modul dar, welches fur die spezielle Anwendung 
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konzipiert ist Ein Beispiel wird nachfolgend anhand der Ferndiagnose in den Figuren 3 
und 4 skizziert. 

In entsprechender Weise ist ein Ablaufsteuerungs-Modul 4e im Fahrzeugendgerat 
vorgesehen. Auch dieses Software-Modul ist fur die spezielle Anwendung konzipiert. Ein 
Beispiei wird nachfolgend anhand der Ferndiagnose in den Figuren 3 und 4 skizziert 
Diese Ablaufsteuerung erzeugt eine Server-Anfrage zur Durchfuhrung einer 
Ferndiagnose. Sie konfiguriert die Funktionen im Fahrzeug, beispielsweise durch 
Festlegen einer Tester-Present-Nachricht, Einstellen der Timing-Parameter fur das 
Transport-Protokoll und gegebenenfalls Einstellen der Parameter fur die CAN- 
Kommunikation. Die Ablaufsteuerung fuhrt ferner die Diagnose-Kommunikation durch 
zyklisches Generierung von Tester-Present-Nachrichten mit den zu diagnostizierenden 
Steuereinheiten durch. Ferner werden von ihr die vom Server ubertragenen Diagnose- 
Kommandos auf das CAN-Transport-Protokoll umgesetzt. Daruber hinaus ubertragt das 
Ablaufdiagramm die Daten an den Server und setzt zu diesem Zweck die im Fahrzeug 
ermittelten Diagnose-Daten auf die Mobilfunkschnittstelle urn. Daruber hinaus sind 
MaBnahmen getroffen, mit denen in einem Ausfuhrungsbeispiel die bewerteten 
Ergebnisse der Fehleranalyse, die vom Server ubermittelt werden, angezeigt werden. 
Ferner ubernimmt die Ablaufsteuerung die Beendigung der Diagnose-Kommunikation 
durch Stoppen der Generierung von Tester-Present-Nachrichten. Daruber hinaus wird in 
einem Ausfuhrungsbeispiel das automatische Beenden eines unterbrochenen 
Diagnosevorgangs, z.B. durch Timeout oder Watchdog fur den Empfang von Server- 
Kommandos, durchgefuhrt. 

Das im Client 4 vorgesehene Transport-Protokoll-Modul 4d fuhrt die Ubertragung von 
komplexen Nachrichten oder Dateneinheiten liber einen CAJN-Bus durch, nimmt die 
Entkopplung des Diagnose-Protokolls vom physikalischen tTbertragungsmedium vor und 
stelit die Dienste des OSI-Layers 3 (Network Layer) zur Verfiigung, sowie die 
Verbindung zwischen dem OSI-Layer 2 (Data Link Layer) und 7 (Applikation Layer). Es 
werden als also vom Transport-Protokoll-Modul eine Segmentierung und Erfassung von 
Daten des Data Link Layers vorgenommen, das heiBt die Steuerung des Datenflusses 
einzelner Botschaften inklusive Verwaltung und Zuordnung von physikalischen CAN- 
Botschaften zu iogischen Nachrichten oder Dateneinheiten sowie die Fehlererkennung. 
Eine Realisierung stelit das allgemein verbreitete ISO-Transport-Protokoll (ISO 15765-2) 
dar, wobei in anderen Anwendungen auch spezielle Varianten dieses Protokolls 



WO 03/105093 




PCT/DE03/01604 



eingesetzt werden. Dies gilt auch bei der Verwendung anderer Bussysteme zur 
Kommunikation mit den Fahrzeugsteuergeraten. 

Das dem Server zugeordnete Diagnose-Protokoll-Modul Id umfasst die Diagnoseschicht, 
weiche in einer bevorzugten Anwendung das nach ISO spezifizierte Diagnose-Protokoll 
KWP2000 enthalt, wobei je nach Ausfuhrungsbeispiel auch Varianten davon eingesetzt 
werden. In diesem Diagnose-Protokoil-Modul sind spezielle Diagnose-Dienste definiert, 
dieje nach Kraftfahrzeughersteller und/oder Kraftfahrzeugtyp unterschiedlich genutzt 
werden und zum Teil unterschiedliche Zusatzdienste enthalten. Das Diagnose-Protokoll- 
Modul wertet die Diagnose-Anfragen aus. Weitere Aufgaben, die durch das Modul gelost 
werden, sind die Konvertierung von Diensten in eine funktionale Schnittstelle fiir die 
Anwendungsschicht, die direkte Nutzung spezieller Dienste und die 
Ausnahmebehandlung bei Nutzung von unbekannten Diensten. Ein Beispiel fur die 
Realisierung eines solchen Modul ist aus den nachfolgend beschriebenen 
Vorgehensweisen entnehmbar. 

Die grundsatzliche Vorgehensweise im Rahmen der Ferndiagnose besteht darin, dass 
nach Aktivierung der Ferndiagnose durch eine Bedienperson, z.B. den Nutzer des 
Kraftfahrzeugs, und/oder den Service-Provider und/oder den Fahrzeughersteller und/oder 
eines Monteurs einer Werkstatt nach Abschluss der MaBnahmen zum Verbindungsaufbau 
zwischen Endgerat und Server die Kommandos des fahrzeugspezifischen Diagnose- 
Protokolls uber die Luftschnittstelle vom Server zum Endgerat ubertragen werden. Die 
fahrzeugspezifischen Diagnose-Protokoll-Kommandos werden dabei vomDiagnose- 
Server nach Identifizierung des zu diagnostizierenden Kraftfahrzeugs aus einer 
Datenbank ausgelesen. Das Endgerat setzt die ubertragenen Diagnose-Kommandos auf 
das Fahrzeugnetzwerk urn. Die erfolgt beispielsweise dadurch, dass die empfangenen 
Kommandos in Kommandos fur das diagnostizierende Steuergerat umgesetzt werden und 
uber die Schnittstelle zum Fahrzeugnetzwerk, insbesondere uber einen CAN-Bus, an das 
Steuergerat gesendet werden. Die Antwort dieses Steuergerats wird als Datennachricht 
aus dem Fahrzeugnetzwerk im entsprechenden Format liber die 
Fahrzeugnetzwerkschnittstelle empfangen und wird dann vom Endgerat in 
Antwortnachrichten fur den Server umgesetzt. Diese werden dann an die 
Mobilfunkschnittstelle ubermittelt, die die Nachricht uber ein vorgesehenes 
Ubertragungs-Protokoll (beispielsweise im Rahmen des GSM-Standards) an den Server 
geschickt wird. Zusammenfassend setzt der Client im bevorzugten Ausfuhrungsbeispiel 
also das vom Server ubertragene Diagnose-Protokoll (KWP2000) auf das CAN- 
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Transport-Protokoll um und umgekehrt. Die Ablaufsteuerung des beschriebenen 
Vorgangs zur Aufrechterhaltung der Diagnose-Kommunikation im Fahrzeug erfolgt im 
Endgerat autark, beispielsweise durch sogenannteTester-Present-Nachrichten. Diese sind 
in der KWP2000-Spezifikation definiert und dienen der Erfiillung der zeitlichen 
Anforderungen der Fahrzeugnetzwerkes. Dadurch wird eine Entkopplung der 
zeitkritischen Diagnose-Kommunikation im Fahrzeug von den zeitunkritischen 
Diagnoseablaufen im Server erreicht. Ergebnis ist somit eine flexible Konfiguration der 
fahrzeugspezifischen Diagnose-Kommunikation im Fahrzeug, die nicht durch mogliche 
Probleme der Luftschnittstelle und der Diagnoseablaufe im Server belastet ist. 

Figur 3 zeigt ein Ablaufdiagramm des Gesamtvorgangs, der in fiinf grundlegende 
Teilschritte gegliedert ist. Die detaillierten Ablaufe innerhalb eines solchen Teilvorgangs 
sind je nach Fahrzeugtyp, dem moglicherweise vorliegenden Fehlerfall und/oder der 
jeweiligen Implementierung des Systems im Diagnose-Server variierbar. Im ersten Schritt 
100 erfolgt das Starten der Diagnose mit einer entsprechenden Anfrage an den Server. 
Die Aktivierung erfolgt dabei im bevorzugten Ausfiihrungsbeispiel durch den Fahrer 
bzw. Nutzer des Kraftfahrzeugs der durch Anruf oder Ahnliches beim Service-Center 
eine Aufforderung des Servers an den Client im Fahrzeug erzeugt, eine Diagnose- 
Verbindung aufzubauen. Der Client baut dann die angeforderte Verbindung auf. In 
anderen Ausfuhrungsbeispielen wird die Diagnose- Verbindung durch eine Anfrage vom 
Client aus aufgebaut. Der Aufbau der eigentlichen Diagnose-Verbindung erfolgt hier 
durch den Server oder den Client. Im nachsten Schritt 200 erfolgt die Konfiguration der 
Ferndiagnose-Funktionalitat im Fahrzeug durch den Server. Dabei wird die 
Ablaufansteuerung, die Transportschicht und gegebenenfalls die CAN-Kommunikation 
an das spezifische Fahrzeug angepasst. Dies erfolgt durch Kommandos bzw. Daten vom 
Server, die dieser aus einer Datenbank fur das spezielle Fahrzeug bzw. Fahrzeugtyp / 
und/oder Austattungsvariante ausliest. Bei der Aktivierung erhalt der Server 
beispielsweise mittels eines Identifikationscodes Informationen uber das zu 
diagnostizierende Fahrzeug. Anhand dieser Information liest er fahrzeugspezifische 
Parameter aus der Datenbank aus, die er dann an den Client zur Konfiguration der 
Ferndiagnose-Funktionalitat ubermittelt. 

Nach den Teilschritten Aktivierung (100) und Initialisierung (200) wird der Teil schritt 
Ausfuhrung des Diagnosevorgangs (301 bis 303) an einem Beispiel eines Steuergerats 
gezeigt. Zunachst wird im Schritt 301 durch den Server im zu diagnostizierenden 
Steuergerat, sofern dies notwendig ist, der Diagnosemode angestoBen, so dass das 
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Steuergerat zum Ausfuhren der Diagnose-Funktion in der Lage ist. Ferner erfolgt die 
Identifikation des Steuergerat, z.B. dessen Softwarestand zur Anpassung der Diagnose- 
Kommandos an den speziellen Steuergeriitetyp. Auch dies ist optional und wird dann 
eingesetzt, wenn dies z.B. aufgrund der Vielzahl von Softstanden sich als erforderlich 
erweist. Danach werden die ausgewahlten Diagnose-Kommandos vom Server an den 
Client im Fahrzeug ubertragen. Beispiele fur solche Diagnose-Kommandos sind das 
Auslesen wenigstens eines Fehlerspeichers des betroffenen Steuergerats, das Auslesen 
von gespeicherten Umgebungs-Parameter eines aufgetretenen Fehlers und/oder das 
Abfragen von zusatzlichen Ist-Werten aus dem entsprechenden Steuergerat. 

Im Schritt 302 setzt der Client das oder die ubermittelten Diagnose-Kommandos auf das 
Fahrzeugnetzwerk urn. Im darauf folgenden Schritt 303 wird die Antwort des 
Steuergerats auf das oder die gesendeten Kommandos, welche beispielsweise innerhalb 
einer bestimmten Zeitperiode auftreten muss, empfangen, vom Client iiber auf die 
Ubertragungsschnittstelle zum Server umgesetzt und an diesen zuriickgesendet. Die 
Schritte 301 bis 303 werden dann fur jedes zu diagnostizierende Steuergerat oder, wenn 
die Diagnosekommandos einzeln nacheinander oder in Gruppen nacheinander versendet 
werden, fur jedes einzelne Diagnose-Kommando oder Diagnose-Kommando-Gruppe 
wiederholt. Ist die Diagnose fur ein Steuergerat beendet, wird als Diagnose-Kommando 
ein Ende-Kommando gesendet, welches ggf. den Diagnose-Mode im Steuergerat 
deaktiviert und dieses wieder in den normalen Betriebsmode zuruckversetzt. 

Der vierte Teilschritt betrifft die Auswertung der erhaltenen Daten im Server (Schritt 
400). Der Server wertet der nach MaBgabe eines ggf spezifischen Algorithmus die 
gesammelten Fehlerinformationen aus, ermittelt ein Diagnose-Ergebnis und/oder 
Empfehlungen fur das weitere Vorgehen. Im darauf folgenden Schritt 500 werden dann 
die vom Server ermittelten Ergebnisse an das Endgerat ubertragen und von diesem im 
Fahrzeug angezeigt. Dieser funfte Teilschritt stelle somit die Ergebnisausgabe dar. Im 
diesem Schritt ist auch in einem Ausfuhrungsbeispiel die Obermittlung und Anzeige einer 
Empfehlung fur das weitere Vorgehen imFehlerfall vorgesehen, z.B. „Werkstatt 
aufsuchen", etc. 

Figur 4 zeigt ein beispielhaftes Kommunikationsszenario zwischen einem Ferndiagnose- 
Server, einem Telematikendgerat und einem Steuergerat. Das Kommunikationsszenario 
stallt eine Realisierung des dritten Teilschritt in Figur 3 im Detail dar. Basis der 
Kommunikation ist das nach ISO 14230-3 spezifizierte Diagnose-Protokoll KWP2000. In 
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anderen Ausfuhrungsbeispielen werden herstellerspezifische Varianten dieses Diagnose- 
Protokolls oder auch andere Diagnose-Protokolle entsprechend eingesetzt. Je nach 
Ausfuhrungsbeispiel variiert die Abfolge der Schritte und der Umfang der Schritte in den 
einzelnen Anwendungen. Figur 4 zeigt eine bevorzugte Realisierung der Kommunikation 
zwischen einem Ferndiagnose-Server I, einem imFahrzeug angeordneten 
Telematikendgerat II und einem zu diagnostizierenden Steuergerat ID. Die 
Kommunikation basiert dabei auf dem Diagnose-Protokoll KWP2000, welches in der 
ISO 14230-3 spezifiziert ist. Die Fehlerermittlung und das Setzen der Fehlerspeicher 
erfolgt dabei in den meisten Falle durch bekannte Diagnosemethoden im zu 
diagnostizierenden Steuergerat durch dort vorhandene oder dort eingelesene Software. 

In Figur 4 sind die einzelnen einer Kommunikation zwischen den drei beteiligten 
Einheiten dargestellt, wobei von oben nach unten eine zeitliche Reihenfolge ausgedruckt 
sein soil. In den Einheiten sind Softwareprogramme vorhanden, die die zu ubermittlenden 
Nachrichten erzeugen, auswerten, etc. 

Nach Abschluss der Teilvorgange 1 und 2 (siehe Figur 3, Schritte 100 und 200) wird in 
einem ersten Schritt SI der Diagnose-Mode im zu diagnostizierenden Steuergerat 
aktiviert. Dazu sendet der Server ein entsprechendes Diagnose-Kommando (Start- 
Diagnostic-Session-Request). Dieses wird vom Endgerat empfangen und uber die 
Schnittstelle zum diagnostizierenden Steuergerat weitergeleitet (Schritt S2) bzw. zuerst in 
ein fur das Fahrzeugnetz geeignetes Format umgesetzt (z.B. mittels einer Tabelle) und 
dann auf das Fahrzeugnetz gegeben. Das zu diagnostizierende Steuergerat antwortet mit 
einer entsprechenden Antwort (Start-Diagnostic-Session-Response), die angibt, ob der 
Diagnose-Mode eingeleitet ist oder nicht. Diese Information sendet das zu 
diagnostizierende Steuergerat im Schritt S3 zum Endgerat, welches wiederum im Schritt 
S4 (ggf. nach Umsetzung auf das vorgesehene Format) die Information zum Server 
iibertragt. 

Daraufhin wird zur Ablaufsteuerung und zur Erfiillung der Zeitanforderung im 
Fahrzeugnetz vom Endgerat II zum Steuergerat III im Schritt S5 eine Kommando 
geschickt (Tester-Present-Request), welches im Schritt S6 von Steuergerat mit einer 
entsprechenden Antwort (Tester-Present-Response) beantwortet wird. Diese 
■ Kommunikation wird im folgenden wahrend des Diagnosevorgangs dann ausgefuhrt, 
wenn vom Server kein anderes Diagnose-Kommando weiterzuleiten ist bzw. vom 
Steuergerat keine Antwort an den Server zu leiten ist. Daher kdnnen die Schritte S5 und 
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S6 auch mehrfach wiederholt werden, solange bis das erwartete Kommando vom Server 
empfangen wird. Tritt eines der genannten Ereignisse nicht auf, wird die Kommunikation 
zwischen Endgerat und Steuergerat abgebrochen.. 

Nach Empfang der Antwort im Schritt S4 sendet der Server im Schritt S7 ein Kommando 
(Read ECU-Identification-Request), welches die Identification des zu diagnostierenden 
Steuergerats anfragt. Dieses Kommando wird vom Endgerat empfangen und ggf. 
umgesetzt und dann im Schritt S8 zum Steuergerat ubermittelt. Das Steuergerat liest aus 
seinem Speicher daraufhin wenigstens einen Identifikationsparameter aus und sendet 
diesen zum Endgerat (Read ECU-Identification-Response, Schritt S9). Diese Information 
wird dann ggf. nach Umsetzung vom Endgerat II im Schritt S10 an den Server 
iibertragen. Anhand des Identifikationsparameters erkennt der Server das Steuergerat, 
gegebenenfalls dessen Software-Stand sowie gegebenenfalls das Fahrzeug und wahlt aus 
der Datenbank entsprechende Parameter aus. In der Zwischenzeit lauft, wie anhand der 
Schritte Sll und S12 dargestellt, zwischen Endgerat und zu diagnostizierenden 
Steuergerat die oben beschriebene Tester-Present-Kornmunikation ab, die sicherstellt, 
dass die Kommunikation zwischen Endgerat und Steuergerat aufrechterhalten bleibt, das 
Steuergerat im Diagnosemode verbleibt und keine Verletzung der Randbedingungen ftir 
die Kommunikation im Fahrzeugsnetz, die zum Abbruch fiihrt, erfolgt. 

In den nachsten Schritten werden die Fehlerspeicher des zu diagnostizierenden 
Steuergerats ausgelesen. Dazu ubermittelt der Server nach Empfang der Nachricht im 
Schritt S 10 und Auslesen der steuergeratspezifischen Parameter zum Endgerat im Schritt 
S13 eine entsprechende Anfrage (Read DTC-Request). In dieser Anfrage sind die 
steuergeratspezifischen Parameter enthalten, in denen z.B. angegeben ist, welche 
Fehlerspeicher auszulesen sind. Diese Anfrage wird im Schritt S14 von Endgerat ggf. 
nach Umsetzung zum Steuergerat iibertragen. Das Steuergerat fuhrt die empfangenen 
Kommandos aus und sendet die Fehlerspeicherinhalte als Botschaft Read DTC-Response 
im Schritt S15 zum Endgerat. Die Botschaft Read DTC-Response enthalt demnach die 
relevanten Fehlerspeicherinhalte. Die Antwort wird vom Endgerat ggf. nach Umsetzung 
im Schritt S16 zum Server iibertragen. Daraufhin wird in den Schritten S17 und S18 die 
oben erwahnte Tester-Present-Kommunikation zwischen Endgerat und Steuergerat bis 
zum erneuten Empfang einer Botschaft vom Server durchgefiihrt. 

Im darauf folgenden, optionalen Teilschritt werden die zu den Fehlereintragen gehorige 
Umgebungsparameter ausgelesen. Zu diesem Zweck sendet der Server nach Empfang der 
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Botschaft im Schritt S16 und nach Auswertung der Fehlereintrage im Schritt S19 an das 
Endgerat eine entsprechende Anfrage (Read-Freeze Frame-Request), die dieses ggf. nach 
Umsetzung im Schritt S20 an das Steuergeriit weitergibt. Je nach Ausfiihrung liest das 
Steuergerat dann die gewiinschten Parameter zu den gespeicherten Fehlern aus oder der 
Server spezifiziert anhand der Inhalte der Fehlerspeicher den Inhalt seiner Botschaft, so 
dass mit dieser Botschaft nur bestimmte Umgebungsparameter angefordert werden. Das 
Steuergerat jedenfalls antwortet mit einer entsprechenden Antwort (Read-Freeze Frame- 
Response), in welchem die auf die eine oder andere Weise angeforderten Parameter 
enthalten sind. Im Schritt S21 wird die Antwort an das Endgerat gesendet, welches die 
Antwort wiederum ggf. nach Umsetzung im Schritt S22 zum Server ubertrag. In den 
Schritten S23 und S24 erfolgt emeut die Tester-Present-Kommunikation. 

Imdarauf folgenden Teilschritt, nach dem Fehlerspeicher und zugehorige 
Umgebungsparameter ausgelesen und ubertragen sind, wird der Diagnosemode im 
Steuergerat deaktiviert. Hierzu schickt der Server eine Aufforderung zum Beenden die 
Diagnosevorgangs (Stop-Diagnostic-Session-Request) an das Endgerat. Dieses gibt die 
Aufforderung zum Beenden an das Steuergerat weiter (Schritt S26), welches mit einem 
entsprechenden Antwortsignal (Stop-Diagnostic-Session-Response) im Schritt 27, mit 
welcher das Steuergerat die Beendigung des Diagnose-Modus mitteilt, antwortet. Diese 
Information wird vom Endgerat im Schritt S28 zum Server ubertragen. Daraufhin (Schritt 
S29) werden die oben dargestellten Teilvorgange 4 und 5 bezuglich Auswertung und 
Anzeige der Diagnose-Ergebnisse und ggf. -Empfehlungen weitergefuhrt. 

Das dargestellte Kommunikationsszenario ist ein Beispiel. In anderen Ausfuhrungen 
fehlen die Schritte zum Aktivieren und Deaktivieren des Diagnose-Modes im Steuergerat 
und/oder zur Identifikation des Steuergerats und/oder zum Auslesen der zugehorigen 
Umgebungsparameter. 

Die konkrete technische Realisierung der dargestellten Kommunikation findet durch 
entsprechende Software-Programme in Server, Endgerat und Steuergerat statt, die jedes 
fur sich ebenfalls Teil der vorliegenden Erfindung sind. 
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Patentanspruche 

1. Verfahren ftir einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind, wobei im Server zeitunkritische 
Funktionalitaten, im Endgerat zeitkritische Funktionalitaten ablaufen.. 

2. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

3. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise im 
Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 

4. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
die zeitkritischen Teilfunktionalitaten autark im Endgerat ablaufen, die 
zeitunkritischen Teilfunktionalitaten vom Server mittels Kommunikatioon mit dem 
Endgerat durchgefuhrt werden. 
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5. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
im Endgerat die zeitkritische Kommunikation mit einem zu diagnostizierenden 
Steuergeriit und/oder einer zu diagnostizierenden Komponenten implementiert ist. 

6. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
der Telematikdienst eine Ferndiagnose eines Kraftfahrzeugs ist und dass das 
Diagnose-Protokoll im Server implementiert ist. 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
Kommandos.des fahrzeugspezifischen Diagnose-Protokolls ubereine 
Luftschnittstelle vom Server zum Endgerat ubertragen wird. 

8. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
das Endgerat die ubertragenen Diagnose-Kommandos auf ein Fahrzeugnetzwerk 
umsetzt und die erzeugten Antwortnachrichten an die Mobilfunkschnittstelle 
ubermittelt. 

9. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
als Diagnose-Protokoll KWP2000 oder eine Variante davon eingesetzt wird. 

10. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind. 

11. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

12. Vorrichtung f ur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise 
im Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 
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13. Vorrichtung nach Anspruch 10 oder 11, wobei der Server iiber eine Luftschnittstelle 
mit dem Endgerat kommuniziert, dadurch gekennzeichnet, dass der Telematikdienst 
eine Femdiagnose eines Kraftfahrzeugs ist, wobei das Diagnose-Protokoll als 
zeitunkritischeTeilfunktionalitat im Server implementiert ist. 

14. Vorrichtung nach Anspruch 10 oder 12, wobei das Endgerat iiber eine 
Luftschnittstelle mit dem Server kommuniziert und welches eine weitere Schnittstelle 
umfasst, mit dem es mit einer zu diagnostizierenden Einheit verbunden ist, dadurch 
gekennzeichnet, dass das Endgerat als zeitkritischeTeilfunktionalitat eine 
Ablaufsteuerung umfasst, die autark gegeniiber der zentralen Recheneinheit ist und 
die die Diagnose-Kommunikation im Fahrzeug aufrecht erhalt. 

15. Computerprogramm mit Programmcode-Mitteln, um alle Schritte von jedem 
beliebigen der Anspruche 1 bis 9 durchzufuhren, wenn das Programm auf einem 
Computer ausgefuhrt wird. 

16. Computerprogrammprodukt mit Programmcodemitteln, die auf einem 
computerlesbaren Datentrager gespeichert sind, um das Verfahren nach jedem 
beliebigen der Anspruche 1 bis 9 durchzufuhren, wenn das Programmprodukt auf 
einem Computer ausgefuhrt wird. 
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